a funny test^_^
hi,guys, i saw a interesting program today,the source code is:
now , i let's have a test, please give the output of the program without computer and post it, then compile the program and run it in your computer, is your answer right?Code:#include <iostream> using namespace std; char a[] = "abcdefg"; char b[] = "1234567"; char c[] = "980123456789"; int main() { strcpy(a, c); strcpy(b, c); cout << a << endl << b << endl << c << endl; return 0; }
Yes, it is.
...and what was this a test of, exactly? Undefined behavior?
Last edited by SlyMaelstrom; 11-26-2006 at 12:09 AM.
Sent from my iPad®
The code yields undefined behaviour, which means that anything is allowed to happen, whether we describe it or not.
afaik, the output is undefined (does the standard make any guarantees of variables being stored in contiguous memory?)
"Think not but that I know these things; or think
I know them not: not therefore am I short
Of knowing what I ought."
-John Milton, Paradise Regained (1671)
"Work hard and it might happen."
-XSquared
just give the ouput of the program
the program runs correctly
the output is unique
and the program will not induce a runtime error
I do get the feeling that where ever s/he got that test from, they were expecting the variables to be defined contiguously.Originally Posted by JaWiB
I'm not sure you could say anything could happen.In fact, on any standard operating system you could really limit the result to one of two things, I suppose.
Says who? Are you going to run it a 1000 times on a 1000 systems to be sure of that?
Last edited by SlyMaelstrom; 11-26-2006 at 12:18 AM.
Sent from my iPad®
the standard make guarantee of the global variables being stored contiguously in the static area of the memory
Last edited by zouyu1983; 11-26-2006 at 12:20 AM.
you can try it ^_^, and i am sure the output is unique without induring any problem
I'd have to see where it said that in the standard; However, I have no reason not to believe you. However, in assembly, if memory is defined to be placed on full word boundaries, then there could be straggling bytes in between. However, the only assembly I really know is 360 Assembler.X86 may work differently for all I know.
Sent from my iPad®
The standard makes no such guarantee. There is certainly no specific guarantee, in this case, that a, b, and c will be adjacent to each other in memory.
You are making the mistake of assuming that, because you see a particular response on your OS with your compiler, that response is somehow standard or universal.
you mean that in ANSI C++ , there is no guarantee aboult it?
maybe i make mistakes.
i will review the standard.
anyway, thanks^_^
What this means is that pointer comparison is only defined within the same object.
Essentially, this means
if ( &a[0] < &b[0] )
is undefined because you're comparing pointers to two different objects.
Being undefined, it means you can make no statement about whether a comes before b, or how much padding there might be between a and b, or anything else useful.
So your program is undefined.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Yep. In ANSI C++ as well as in ISO C++ (the ANSI C++ standard is also the ISO C++ standard).
As do we all.
i'm sorry, the output of the program is undefined
now give the answer i test
in windows xp sp2 vc.net 2003, the output is:
98012345980123456789
980123456789
6789
in windows xp sp2 g++, the output is
98012345980123456789
980123456789
6789
but in linux + g++, the output is
6789
980123456789
980123456789
